home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group92c.txt / 000057_icon-group-sender _Tue Nov 3 14:00:00 1992.msg < prev    next >
Internet Message Format  |  1993-01-04  |  2KB
  1. Received: by cheltenham.cs.arizona.edu; Tue, 3 Nov 1992 16:44:33 MST
  2. Message-Id: <199211032038.AA22280@optima.cs.arizona.edu>
  3. From: nowlin@iwtqg.att.com
  4. Date: Tue, 3 Nov 92 14:00 CST
  5. To: att!cs.arizona.edu!icon-group
  6. Subject: Re: semicolons
  7. Status: R
  8. Errors-To: icon-group-errors@cs.arizona.edu
  9.  
  10.  > Personally, I like using semicolons and think they increase
  11.  > readability. The compiler/interpreter does a good job of determining
  12.  > where to put automatic semicolons, but it is harder for me to read a
  13.  > series of non-semicoloned lines especially when some of the statements
  14.  > are on more than one line. I don't mind the feature of optional
  15.  > semicolons (mostly because I've never been burned by the compiler
  16.  > inserting a semicolon where I didn't want one), but I almost always
  17.  > use them.
  18.  
  19. I have an idea.  Suppose we cobble up a version of Icon that requires
  20. semicolons to make those of you who feel the need for some kind of
  21. syntactic security blanket happy.  But I'd even go further.  Why not a
  22. version of Icon that requires expressions to start in column ten and
  23. comments to start in column one.  Then we could require type declarations
  24. and add gotos to the language.  Heck, we could even require that it be
  25. submitted on punched cards and that your output be on paper.  Maybe paper
  26. tape instead of cards.  Maybe it could only run on PDP machines and you
  27. have to enter the program by toggling the switches on the front panel.
  28. Maybe ...  Seem like we're going the wrong direction here?
  29.  
  30. Jerry Nowlin
  31.